home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000824-20010305
/
000074_news@columbia.edu _Mon Oct 16 17:09:36 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2001-03-05
|
6KB
Return-Path: <news@columbia.edu>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA18055
for <kermit.misc@cpunix.cc.columbia.edu>; Mon, 16 Oct 2000 17:09:36 -0400 (EDT)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA15733
for <kermit.misc@watsun.cc.columbia.edu>; Mon, 16 Oct 2000 17:09:35 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id QAA01178
for kermit.misc@watsun.cc.columbia.edu; Mon, 16 Oct 2000 16:40:25 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@columbia.edu (Frank da Cruz)
Subject: Re: No Carrier
Date: 16 Oct 2000 20:40:24 GMT
Organization: Columbia University
Message-ID: <8sfp3o$14n$1@newsmaster.cc.columbia.edu>
To: kermit.misc@columbia.edu
In article <%ZHG5.54658$bI6.1914001@news1.giganews.com>,
Steve <steve@baus-systems.com> wrote:
: We currently have DOS clients that on a regular basis, communicate with a
: host PC to exchange files. The clients and the host are running DOS apps
: that call Kermit 3.15. We would like to upgrade the host to K95 to allow
: for multiple transfers at one time on one PC.
:
: Here is what we are doing:
: The host waits in server mode for a client to connect. The clients connects
: either through a serial cable or modem...
:
So then you need one serial port for each simultaneous session. As you know,
PCs are not easily able to accommodate more than two serial ports, due to
the severe shortage of available IRQs in the PC architecture. Any serial
ports beyond two are likely to introduce interrupt conflicts.
: ... and sends across a file that contains
: a field that tells the host which client this is then the client sends a
: Finish command to kick the host out of server mode. The host opens the file
: to get the client ID then changes to a directory containing files specific
: to that client that are waiting to go to the client, compresses the files
: and sends across the compressed file. The host then goes into server mode
: waiting for the clients compressed data file. After the client sends the
: file it sends a Finish command and the host uncompresses the file and
: processes the data, copying files contained within the compressed data file
: to the appropriate places. The host then goes back into server mode waiting
: for the next client.
:
All this switching into and out of server mode sounds pretty tricky to me.
How do the two sides stay synchronized? Wouldn't it be better to keep the
host in server mode and drive everything from the client script?
For example, make the client ID correspond to a directory on the host.
Then the client script could:
. CD to its own host directory.
. Does a GET command for the files that are waiting. Note that both
K95 and MS-DOS Kermit 3.15 have a RETRIEVE command, which means
"send me the specified files, and then delete each one if and only
if it is sent successfully" (in K95, this is equivalent to GET /DELETE).
This feature is designed for exactly your kind of application. For
more discussion of "atomic file movement", see:
http://www.columbia.edu/kermit/case10.html
. I would guess that the compression step can probably be skipped, since
the modems take care of that transparently. In those cases where you
might not have a data-compressing modem connection, the improved
simplicity might be worth the tradeoff. Conversely, you have have the
client script obtain send "remote host zip" or similar commands.
. Now the client sends back its files and sends FINISH, and hangs up its
connection.
This makes the server end quite simple.
: One other important part is from time to time a phone
: line can go bad in the middle of a transfer and therefore for example the
: host may be waiting for the clients compress data file while a new client
: may be connecting and sending the client ID file.
:
This, of course, points up the dangers of using a DOS/Windows server, which
has no notion of separate user identities or authentication. You would solve
an awful lot of programs by using some form of Unix (such as Linux or SCO)
on the server. This gets you user IDs, file protection and permissions, and
all the rest automatically, not to mention the natural ability of the Kermit
server to run subprocesses without hanging.
: We refer to this as the
: client and the host being out of synch. To resolve this, when the client
: first connects, it sends 2 Finish commands which 100% guarantees that the
: host will be at the "waiting for client ID" section of the host app as that
: part of code on the host looks something like:
: Do While True
: Kermit server
: If File(ClientID)
: Exit Do
: End If
: End Do
:
: We would like to upgrade the host app to K95 and have a VB app that seems to
: work fine except for communicating over the modem. When we send the Finish
: from the client, it drops the line and we get No Carrier on the client. If
: we could get around this, that should solve our issue. I am not sure
: changing the software on the client is a realistic option as updating the
: clients is a major hassle.
:
Still, it might be worth it. The current scheme has too many vulnerabilities,
both procedural and security-related.
: We can change the modem initialization string on the clients so that is an
: option.
:
: Any thoughts?
:
It's up to you. If you can't change the client scripts, then you'll need
to make the server script take every possibility into account. If you want
to continue with your current scenario, Jeff already made the suggestions
you need -- remove the EXIT command from your script, and have the script
loop back and wait for another call. Or put two SERVER commands in a row.
Whatever you need to do, the scripting language will allow -- you just need
to think through all the possibilities.
Another possibility is to simply run K95 host mode on server:
http://www.columbia.edu/kermit/k95host.html
In that case, the client script has to log in and negotiate the menus, but
that's not too difficult, and then at least you have some measure of
authentication and file protection.
- Frank